磐舟一體化云交付平臺(tái)是中國(guó)移動(dòng)自主研發(fā)的面向開發(fā)人員的代碼開發(fā)，自動(dòng)部署的平臺(tái)。磐舟一體化交付平臺(tái)自研實(shí)現(xiàn)了一套GitOps驅(qū)動(dòng)引擎，支持從需求設(shè)計(jì)、開發(fā)構(gòu)建、測(cè)試部署的全部開發(fā)與運(yùn)維功能需求，實(shí)現(xiàn)應(yīng)用一鍵上磐基容器云平臺(tái)。

磐基容器云平臺(tái)是中國(guó)移動(dòng)信息公司基于Kubernetes構(gòu)建的企業(yè)級(jí)PaaS解決方案，實(shí)現(xiàn)Kubernetes能力的標(biāo)準(zhǔn)化封裝及調(diào)用，包括提供開發(fā)和運(yùn)行環(huán)境、資源彈性伸縮、精細(xì)化微服務(wù)管理、便捷一站式服務(wù)、跨地域多集群調(diào)度和智能監(jiān)控維護(hù)等六大能力。

磐舟和磐基是相互配合的，開發(fā)人員在磐舟集群上開發(fā)，部署到磐基PaaS集群上運(yùn)行應(yīng)用，也支持在磐舟上歸檔磐基集群ops配置，通過GitOps來管理、部署磐基集群。

隨著國(guó)產(chǎn)化進(jìn)程推進(jìn)，中國(guó)移動(dòng)建設(shè)了大量的國(guó)產(chǎn)化服務(wù)器集群，磐基磐舟如何實(shí)現(xiàn)國(guó)產(chǎn)化的容器云開發(fā)交付一體化體系?在某資源池我們需要統(tǒng)一管理近500臺(tái)鯤鵬服務(wù)器，源碼可以通過磐舟統(tǒng)一編譯為X86/ARM雙架構(gòu)的鏡像，但是集群的管理也需要實(shí)現(xiàn)ARM自動(dòng)化支持，開發(fā)交付環(huán)節(jié)頻繁使用Kubernetes集群，最近2個(gè)月已有800多次的集群創(chuàng)建回收動(dòng)作，人工支撐顯然已經(jīng)跟不上云原生的發(fā)展速度了。

另一個(gè)場(chǎng)景是，移動(dòng)的開發(fā)人員在集團(tuán)磐舟Kubernetes集群上進(jìn)行開發(fā)，制作好鏡像后，不能直接推送到省測(cè)公司的Kubernetes集群，需要運(yùn)維人員在磐基中心集群上通過多級(jí)ssh跳板機(jī)，手工登錄到省公司磐基K8s集群進(jìn)行部署。這一步?jīng)]有實(shí)現(xiàn)自動(dòng)化，操作流程十分繁瑣。

想解決這些問題，我們進(jìn)行了一些頭腦風(fēng)暴。

首先是考慮是否可以將集群統(tǒng)一?答案顯然是不行。因?yàn)榧瘓F(tuán)k8s集群，由于業(yè)務(wù)不同，不能和省公司的k8s集群合為一體。

那么是否可以做k8s的集群聯(lián)邦?目前集團(tuán)集群與省公司集群之間可能是比較遠(yuǎn)的(跨省)，集群聯(lián)邦的整體消耗會(huì)大一些，并且目前跳板機(jī)的場(chǎng)景，跳到省公司集群一臺(tái)機(jī)器上就夠了，不需要看到省公司的所有機(jī)器。

維持ssh現(xiàn)狀，維護(hù)shell腳本?shell腳本需要人力維護(hù)，在省公司的節(jié)點(diǎn)邏輯很可能需要使用service來完整，繼續(xù)維護(hù)shell，第一不是那么CloudNative，第二也背離了磐基磐舟輕松上云的初衷。

本著達(dá)到靈活、易用，提升集群部署時(shí)效，解決端到端開發(fā)運(yùn)維效率，成就內(nèi)部客戶的目的，我們針對(duì)整體場(chǎng)景做了進(jìn)一步抽象，抽象成“1+31+N”的典型網(wǎng)絡(luò)模型。

1個(gè)中心+“31+N”個(gè)邊緣集群的場(chǎng)景，中心與集群、集群與集群，集群與N之間，存在著網(wǎng)絡(luò)隔離與網(wǎng)絡(luò)不可預(yù)知的情況;在這些集群之間，保持網(wǎng)絡(luò)隔離的情況下，在中心節(jié)點(diǎn)做到云原生體驗(yàn)的自動(dòng)化運(yùn)維，做到GitOps自動(dòng)化。

帶著抽象之后的這個(gè)模型，我們?cè)谄脚_(tái)管理上進(jìn)行了深入調(diào)研，最終選用了CNCF的邊緣計(jì)算項(xiàng)目KubeEdge來解決完成以上所有集群的統(tǒng)一管理。

KubeEdge是什么?解決什么問題?

KubeEdge的特點(diǎn)是在云邊通信的資源消耗小，使用方式基于Kubernetes，上手方便，比較適合我們當(dāng)前的場(chǎng)景。KubeEdge項(xiàng)目是華為云開源的一個(gè)基于Kubernetes的開放平臺(tái)，并為網(wǎng)絡(luò)應(yīng)用提供基礎(chǔ)架構(gòu)支持，提供云和邊緣之間的部署和元數(shù)據(jù)同步。

KubeEdge具有以下幾點(diǎn)關(guān)鍵優(yōu)勢(shì)：

1)容器化應(yīng)用封裝

Build once, run anywhere

輕量化基礎(chǔ)鏡像，降低資源占用

2)通用的應(yīng)用抽象定義

業(yè)界事實(shí)標(biāo)準(zhǔn)

云上、邊緣統(tǒng)一管理

3)松耦合的架構(gòu)

易擴(kuò)展的API框架

易于定制平臺(tái)組件

KubeEdge 在架構(gòu)上分為云端組件 CloudCore 和邊緣側(cè) EdgeCore，詳細(xì)的架構(gòu)細(xì)節(jié)可以參考文檔：https://docs.kubeedge.io/en/docs/architecture/

磐舟磐基平臺(tái)的KubeEdge實(shí)踐

通過對(duì)KubeEdge的應(yīng)用場(chǎng)景分析，以及對(duì)移動(dòng)內(nèi)部1+31+N模型結(jié)合，我們可以將集團(tuán)的“1”想象為KubeEdge的CloudCore節(jié)點(diǎn)、將各省公司的node節(jié)點(diǎn)想象為EdgeCore節(jié)點(diǎn)，從而就實(shí)現(xiàn)了1+31+N下的云邊協(xié)同模型。映射到我們的具體場(chǎng)景是這樣：

1)集群業(yè)務(wù)部署場(chǎng)景：

把集團(tuán)的K8s master節(jié)點(diǎn)作為KubeEdge的CloudCore節(jié)點(diǎn)，省公司的node節(jié)點(diǎn)作為KubeEdge的EdgeCore節(jié)點(diǎn)，CloudCore節(jié)點(diǎn)與EdgeCore節(jié)點(diǎn)連接上后，在EdgeCore上啟動(dòng)磐舟GitOps業(yè)務(wù)中ArgoCD pod，統(tǒng)一下發(fā)CD一體化的元數(shù)據(jù)，從而將省公司資源池做到方便的集群創(chuàng)建、集群納管，最終方便的達(dá)成自動(dòng)化GitOps交付。

2)集群自動(dòng)化創(chuàng)建場(chǎng)景：

基于省公司的資源池來創(chuàng)建磐基PaaS集群，運(yùn)維人員在master節(jié)點(diǎn)使用磐舟GitOps，通過CloudCore與EdgeCore的通信，部署來自openEuler社區(qū)的集群自動(dòng)化部署工具-eggo的實(shí)例。之后在邊緣側(cè)，就可以通過eggo來自動(dòng)化完成省公司磐基PaaS集群的創(chuàng)建。

綜上，通過將KubeEdge集成至磐基PaaS平臺(tái)，成功打通移動(dòng)集團(tuán)與各省公司的網(wǎng)絡(luò)，實(shí)現(xiàn)“1+31+N”的K8S集群全部連通、實(shí)現(xiàn)統(tǒng)一管理、簡(jiǎn)化多集群的運(yùn)維系統(tǒng)、減少運(yùn)營(yíng)成本;同時(shí)也成功將前面提到的500臺(tái)鯤鵬服務(wù)器以及它上面的BC-Linux for Euler集群納入磐基PaaS平臺(tái)的大家庭之中，運(yùn)維效率大幅增加。

磐舟磐基平臺(tái)在多集群管理的下一步計(jì)劃

在完成KubeEdge集成到磐舟磐基平臺(tái)這項(xiàng)專項(xiàng)工作之后，考慮到后續(xù)不僅是由master節(jié)點(diǎn)納管單個(gè)edge節(jié)點(diǎn)，還會(huì)考慮在將南向集群的單個(gè)節(jié)點(diǎn)組成一個(gè)集群，實(shí)現(xiàn)控制面的自動(dòng)化集群部署，支撐省公司集群的控制面自動(dòng)化。磐舟磐基平臺(tái)計(jì)劃進(jìn)一步集成CNCF社區(qū)最新的集群聯(lián)邦方案Karmada來完成“1+31+N”的PaaS多集群統(tǒng)一管理工作。

關(guān)鍵詞： 磐舟一體化云 中國(guó)移動(dòng) 企業(yè)級(jí)解決方案 開發(fā)平臺(tái)